Modern integrated circuits (ICs) are developed through the use of hardware description languages (HDLs). HDLs such as VERILOG, VHDL, and the like allow developers to create software-based representations of circuit designs. One advantage of using an HDL is the potential for code reuse from one design to another. This concept has been realized with the commercial availability of intellectual property (IP) cores. In general, an IP core refers to a software representation of a semiconductor, or a portion of a semiconductor, that provides a processing function.
Before HDL logic is made available for commercial use, it must be thoroughly tested and verified. The HDL logic must be tested to ensure that it functions properly and as expected, particularly as defined in the design specification. Typically, this testing is performed using a simulation environment which includes a test harness comprised of HDL descriptions that specify the behavior of a device under test (DUT), in this the case HDL logic such as one or more IP cores. Generating a test harness involves describing the connections, events, and test vectors for different combinations of transactions involving the DUT. In general, the simulation environment provides a deterministic input sequence to the DUT and observes the response, or output, from the DUT.
FIG. 1 is a schematic diagram illustrating an exemplary simulation environment 100. Simulation environment 100 can include a generator 105, a transactor 110, a monitor 115, and a scoreboard 120, each being implemented as a software module or component. Typically, simulation environment 100 is multithreaded in nature, with each of the aforementioned software components operating in a different thread of execution. These components interact with a DUT 125 to perform testing and/or verification. In terms of functionality, the generator 105 can randomly construct data units to be provided to the DUT 125. The transactor 110 can transmit the constructed data units to the DUT 125. The monitor 115 receives processed data units as output from the DUT 125, while the scoreboard 120 compares the input and output units to determine whether the DUT 125 behaved correctly.
In order to adequately test the DUT 125, a series of different test cases, referred to as a test or verification suite, is needed. Each test case can be directed to testing a particular functionality of the DUT 125 and, as such, can include a sequence of user-specified commands. The simulation environment 100 executes these commands, thereby causing particular inputs to be provided to the DUT 125.
Many modern circuit designs are highly parameterizable. That is, the circuit designs can be configured in a variety of different ways depending upon the values assigned to generics and/or parameters of the design. Ideally, to adequately test the circuit design, these generics and parameters should be varied across all tests of the verification suite. Hardware verification languages having randomization engines allow various aspects of a test, such as the inputs to be provided to the DUT 125, to be randomly selected.
Randomization, however, is not available for selecting other parameters of the test case such as the particular DUT configuration to be used. Such is the case because all generics and parameters of the DUT must be specified when the simulation environment is compiled. Accordingly, test personnel must manually specify the DUT configuration, or parameterization, to be implemented prior to running one or more tests of the verification suite. If a different configuration is to be tested, the test personnel manually change the generics and/or parameters of the DUT, re-compile the simulation environment, and restart the testing.
It would be beneficial to provide a technique for testing various configurations and/or parameterizations of a circuit design across multiple tests of a verification suite in a manner that overcomes the limitations described above.